Biggs' Apps

January 27, 2021

muddying the waters (statements and expressions)

Some things are fruits. Some thing are books. It's nice to know which is which. That way you don't end up trying to eat books or study for your exams with a pineapple.

In programming the same applies, especially when debugging. The more complicated the code, the more essential it is that you know what each aspect of the code does. If a bit of code is not obviously clear, you might miss an important meaning. In their bizarre fear of avoiding "boilerplate code" (not that that's really a bad thing), the designers of kotlin obfuscate like crazy.

Because there is differing usages, I first need to make a few definitions. I will use the term statement to mean an atomic programming idiom that does not return a value. Its use is primarily by side effect. Flows of control are common examples of statements (but there are many others). Statements are executed.

Expressions are programming idioms that return a value. This value can be assigned to variables, passed along to other parts of the program, or used in many other ways. Expressions are evaluated.

C programmers are used to blurry statements and expressions. From the beginning, C was designed for professional programmers--people who really know what they are doing, don't need any help, and don't want anything to get in their way. To aid that paradigm, C was designed to make it easy to combine all sorts of code. So every programming idiom in C returns a value, even if it's never used. That means that each and every bit of C is an expression, even execution control.

Because of the many horrors generated by good and not-so-good C programmers, the designers of Java put the brakes on a lot of this crazy business. They separated statements from expressions. And schools everywhere started using Java to teach programming. Many thought this was good. Programmers who complained still had C (or C++).

Then some people complained that Java was too verbose. These are all young people who didn't know that Java was verbose on purpose. They just looked at the new very high level languages and envied those little programs, oblivious to the evolution that caused Java's design in the first place.

So they made a new language based on what they knew, which of course is not that much. Just very modern languages like Python, Javascript, Ruby, and a few others. Many of these languages have enormous libraries that do nearly everything except tie your shoes. That is what kotlin attempts to do (I bet tying your shoes will be implemented in version 1.8--bugs finally worked out in version 6.2).

---

I'm going to talk about one instance for now. Maybe when I'm less lazy I'll go in to the many dozens of examples, but this is good enough. I found it in a beginner's kotlin book--early in the first chapter.

If-else

This nearly universal programming construct has a hidden feature in kotlin--it can return a value! Wait, isn't if-else a way to control the execution path? Yup. But it's now also a way to assign values? Yup. So it's both a flow control and an expression evaluator. Yup.

And sometimes, don't we nest if-else? Yup. And sometimes it can get kind of complicated? Yup. Then doesn't adding the possibility of changing values at the same time make something that's kind of complicated...very complicated? Oh yes indeed!

And if the if-else clauses are kind of long, it's easy to miss the essential first line--the only place where you'd know that this is really an assignment. Aaargh!

Aaaannnd, cut and paste errors are greatly increased when code has multiple purposes. Think about it: you've been assigned to something similar to some already existing code. You see the section of code that does what you want, control-c copy, control-v paste, and there you have it. But wait! It doesn't work. Somewhere in those nested if-else statements you missed an essential assignment; your code doesn't work because something essential (the assignment) was outside the scope of the if-else statement. Easy to miss, so very hard to figure out.

Hence - Muddying the Waters

Of course all you C programmers out there are thinking, "Hey, we've been doing that since the seventies." And you're right. In C everything returns a value. So some C programmers have used this side effect for a very long time. But it's risky--so easy to miss something, so easy to misunderstand, and oh so easy to generate cut-and-paste errors this way. Consequently many C programmers have figured out to use this very sparingly (if at all). The designers of kotlin should have learned this lesson. Apparantly not.